TITLE OF THE INVENTION 

CONTENT RETRIEVAL DEVICE 

BACKGROUND OF THE INVENTION 
5 Field of the Invention 

[0001] The present invention relates to a content retrieval 
device, and more particularly, to a content retrieval device that 
is constructed to permit use of a plurality of connection methods 
and retrieves content data from a server via a communication 
10 network under an optimum connection method. 

Description of the Background Art 
[0002] In recent years, browsing of home pages (Web pages) and 
exchanges of emails on the Internet have attained great popularity . 

15 To access the Internet, the user operates a content retrieval 
device typified by a cellular phone . The content retrieval device 
first establishes connection to a user-subscribing network (for 
example, a mobile communication network) for access to the 
Internet. The content retrieval device then accesses a server 

2 0 on the Internet and retrieves content data typified by a home page 
or an email via the network according to the operation by the user . 
[0003] Conventionally, partly because of a low transfer rate 
in a network, servers mainly handled small-size content data such 
as text files and still picture files. However, with the recent 

2 5 technological advances, in which the content retrieval devices 

1 



have achieved enhanced performance and the transfer rate in a 
network has dramatically improved. Accordingly, servers are now 
able to handle large-size content data such as moving picture 
files and audio files. 
5 [0004] Conventional content retrieval devices access a 
network under either one of two connection methods, circuit 
switching connection and packet switching connection. In the 
circuit switching connection, one physical communication path is 
established between one caller and one call receiver. Since the 

10 caller and the call receiver occupy one communication path from 
the start of a call to the finish thereof in the circuit switching 
connection, data communication between the caller and the call 
receiver is free from influence of other data communication . That 
is, the communication delay, which means time required to deliver 

15 data from a sender to a receiver, can be made substantially 
constant, and thus it is easy to assure a transfer rate. With 
this feature, the circuit switching connection is suitable for 
occasions of transmitting large-size content data to the same 
receiver, such as multimedia phones and moving picture 

20 distribution. 

[0005] In the packet switching connection, a communication 
path is not occupied by one call but is shared with other calls, 
contrary to the circuit switching connection. On the shared 
communication path, data is divided into packets and transmitted 

25 together with other packets for other call exchanges. The packet 



switching connection therefore permits effective use of 
communication path resources and thus reduction of the 
communication cost. However, the packet switching connection 
generates troubles such as loss of packets and reversal of the 
5 order of arrival of packets, and thus fails to achieve constant 
communication delay, unlike the circuit switching connection. 
That is, in the packet exchanging connection, it is not easy to 
assure a transfer rate. Moreover, since packets for one call 
exchange must be distinguished from those for other call exchanges , 

10 each packet includes identifiers representing the sender and the 
receiver in addition to data to be transmitted. The effective 
transfer rate is therefore lower in the packet switching 
connection than in the circuit switching connection. The 
effective transfer rate as used herein refers to the transfer rate 

15 for data only, excluding control information such as identifiers . 
In view of the above, the packet switching connection is suitable 
for occasions where communication delay causes no significant 
problem or where data communication is not always active 
throughout the call period, such as exchanges of emails. 

20 [0006] Conventionally, the content retrieval devices used 
only either one of the circuit switching connection and the packet 
switching connection. Recently, there has been developed a 
content retrieval device that can selectively use either the 
circuit switching connection or the packet switching connection. 

25 An example of such a content retrieval device is an inter-LAN 



connection device disclosed in Japanese Patent Gazette No. 
2625388. The inter-LAN connection device is applied to systems 
that execute data communication via ISDN (integrated services 
digital network) . The inter-LAN connection device monitors the 
5 data transfer amount on a communication path, and selects either 
the circuit switching connection or the packet switching 
connection based on the data transfer amount and the communication 
traffic amount, which means communication density of data on a 
communication path, for each transaction. 

10 [0007] The inter-LAN connection device monitors data 
communication actually executed and selects either the circuit 
switching connection or the packet switching connection based on 
the status of the monitored data communication. Therefore, it 
is difficult for the device to select the connection method 

15 suitable for coming data communication. The inter-LAN 
connection device has another problem as follows . The connection 
method may be switched depending on the status of data 
communication. In such an event, communication delay is caused 
by the time required to complete the switching from one connection 

20 method to the other when continuous data communication without 
interruption is required, for example, when a moving picture file 
is transmitted. In view of the above, the inter-LAN connection 
device is not suitable for data having a nature that communication 
delay and interruption of data communication are fatal. 

25 [0008] To solve the above problems, the inter-LAN connection 



device is provided with a transaction information setting section 
that sets an attribute of data exchanged for each transaction as 
transaction information. By referring to the transaction 
information setting section, coming data to be exchanged is 
5 predicted and a suitable connection method for the data is 
selected. However, on the Internet, various types of data such 
as text files , moving picture files , and audio files are available . 
Therefore, it is difficult for the inter-LAN connection device 
to correctly predict coming data to be exchanged. 

10 

SUMMARY OF THE INVENTION 

[0009] Therefore, an object of the present invention is to 
provide a content retrieval device that selects a suitable 
connection method prior to data reception. 
15 The present invention has the following features to 

solve the problem above. 

[0010] One aspect of the present invention is directed to a 
content retrieval device having a multi-call function allowing 
use of a plurality of connection methods for retrieving content 

2 0 data from a server via a communication network under an optimum 
connection method. The content retrieval device includes: a 
browser section for generating a retrieval request specifying 
locational information of content data to be retrieved presently ; 
a protocol control section for determining a connection method 

25 for the content data specified by the browser section prior to 



reception of the content data; and a communication control section 
for receiving the content data specified by the browser section 
from the server under the connection method determined by the 
protocol control section. 
5 [0011] These and other objects, features, aspects and 
advantages of the present invention will become more apparent from 
the following detailed description of the present invention when 
taken in conjunction with the accompanying drawings. 



10 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a functional block diagram of a content 
retrieval device la. 

FIGS. 2A and 2B are views of the data structure of 
response data Drep generated by a content server 3 in FIG. 1 and 
15 an internal information table Tconnl, respectively. 

FIGS. 3A and 3B are views showing the relationship 
between main content data Dmc and sub-content data Dsc. 

FIG. 4 is a block diagram of a mobile communication unit 
Ucomml to Ucomm4 . 
20 FIG. 5 is a flowchart of the operation of the mobile 

communication unit Ucomml . 

FIG. 6 is a functional block diagram of a content 
retrieval device lb. 

FIGS. 7A and 7B are views of a connection information 
25 table Tconn2 and an internal information table Tctyp, 
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respectively . 

FIG. 8 is a flowchart of the operation of the mobile 
communication unit Ucomm2 . 

FIG. 9 is a functional block diagram of a content 
5 retrieval device lc. 

FIG. 10 is a view of a connection information table 

Tconn3 . 

FIG. 11 is a flowchart of the operation of the mobile 
communication unit Ucomm3 . 
10 FIG. 12 is a functional block diagram of a content 

retrieval device Id. 

FIG. 13 is a flowchart of the operation of the mobile 
communication unit Ucomm4 . 

15 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0012] FIG. 1 is a functional block diagram of a content 
retrieval device la of a first embodiment of the present invention . 
FIG. 1 also shows a communication network 2 and a content server 
3 in association with the content retrieval device la. The 

20 content retrieval device la has a multi-call function that permits 
retrieval of content data Dc from the content server 3 by either 
one of the connection methods, the packet switching connection 
and the circuit switching connection. The content retrieval 
device la accesses the content server 3 via a first communication 

25 path 4pkt during the packet switching connection, while it 



accesses the content server 3 via a second communication path 4tel 
during the circuit switching connection. To realize the data 
communication described above, the content retrieval device la 
includes a browser section Pbw, a protocol control section Ppc , 
5 a first communication control section Peel, and a second 
communication control section Pcc2 . 

[0013] The content server 3 stores some content data Dc, each 
of which is typically a text file described in a markup language 
typified by Hypertext Markup Language (HTML) , an audio file, a 

10 still picture file, or a moving picture file. HTML permits 
linking of one content data Dc to another content data Dc 
(so-called hyperlink) . In this embodiment, the content data Dc 
in which a link originates is hereinafter referred to as main 
content data Dmc, and the content data Dc as a linked target is 

15 hereinafter referred to as sub-content data Dsc. 

[0014] To achieve hyperlink, the main content data Dmc 
includes an anchor tag Tanc that specifies locational information 
Iurl (that is, URL (uniform resource locator) , specified as urll 
or url2 in FIG. 1) indicating the storage location of sub-content 

20 data Dsc. In this embodiment, the anchor tag Tanc also includes 
connection method information Iconnl (connection method 
information Iconnll or Iconnl2 is illustrated in FIG. 1) as an 
attribute value. The connection method information Iconnl 
indicates a suitable connection method under which the content 

25 retrieval device la suitably retrieves the sub-content data Dsc. 



In this embodiment, two types of connection method information 
Iconnl are defined: the connection method information Iconnll 
indicating that the suitable connection method is the packet 
switching connection, described as cc=packet, and the connection 
5 method information Iconnl2 indicating that the suitable 
connection method is the circuit switching connection, described 
as cc=tel. 

[0015] FIG. 1 exemplifies one main content data Dmc and two 
sub-content data Dscl and Dsc2 as the sub-content data Dsc. As 

10 the locational information lurl of the main content data Dmc, urlO 
is allocated, which has a form like 

http://www.xxx.co.jp/main.html. Assume that the sub-content 
data Dscl is a text file or a still picture file to which 
communication delay and interruption of data communication are 

15 not fatal, that is, a file suitably retrievable under the packet 
switching connection. Contrarily, assume that the sub-content 
data Dsc2 is an audio file or a moving picture file to which 
communication delay and interruption of data transfer are fatal, 
that is, a file suitably retrievable under the circuit switching 

20 connection. Assume also that the locational information lurl of 
the sub-content data Dscl is urll and that of the sub-content data 
Dsc2 is url2 . Under the above assumption, the main content data 
Dmc has descriptions of two anchor tags Tancl and Tanc2 . The 
anchor tag Tancl includes descriptions of >A href =urll " and 

25 "cc^packet", while the anchor tag Tanc2 includes descriptions of 



w href=url2" and *cc=tel". 

[0016] Hereinafter, the operation of the content retrieval 
device la will be described. The protocol control section Ppc 
receives a content retrieval request Dcreq from the browser 
5 section Pbw. Assume that the present content retrieval request 
Dcreq is generated in response to an input by the user of the 
content retrieval device la and includes the locational 
information lurl of the main content data Dmc (that is, urlO) . 
The protocol control section Ppc passes the received retrieval 

10 request Dcreq to the first communication control section Peel, 
instructing to retrieve the main content data Dmc. In response 
to this instruction, the first communication control section Peel 
first establishes the first communication path 4pkt to the content 
server 3 according to the packet switching connection 

15 requirements , if the connection has not been established, and then 
transmits the retrieval request Dcreq to the content server 3 . 
[0017] The first communication path 4pkt is used for retrieval 
of the main content data Dmc as described above. This is because, 
since the main content data Dmc is a file in which a link originates , 

20 the connection method suitable for this retrieval is not specified 
in the anchor tag Tanc . In addition, the communication cost is 
generally lower in the packet switching connection than in the 
circuit switching connection since many users share the first 
communication path 4pkt . 

25 [0018] The content server 3 reads the content data Dc based 



on the locational information Iuri in the received retrieval 
request Dcreq, and generates a response header He and response 
data Drep. The content data Dc read presently is main content 
data Dmc. The response header He generated presently is a 
5 response header Hrac for the main content data Dmc, which includes 
a protocol identifier IDprt, a response result code Crep, a 
content type Ictyp, and a content data length Iclg as shown in 
FIG. 2A. The protocol identifier IDprt specifies the protocol 
for the present data communication . The response result code Crep 

10 specifies the response result to the present retrieval request 
Dcreq. The content type Ictyp indicates the type of the presently 
read content data Dmc. Here, assume that the present content type 
Ictyp indicates that the content data Dmc is described in HTML. 
The content data length Iclg indicates the size of the presently 

15 read content data Dmc. The response data Drep prepared presently 
is response data Drepl for the main content data Dmc . The response 
data Drepl, which includes the main content data Dmc and the 
above-described response header Hmc added to the main content data 
Dmc, is transmitted to the content retrieval device la via the 

20 first communication path 4pkt. 

[0019] In the content retrieval device la, the first 
communication control section Peel receives the response data 
Drepl via the first communication path 4pkt and passes the data 
to the protocol control section Ppc as it is . The protocol control 

25 section Ppc identifies the type of the content data Dc from the 



preceding content type Ictyp in the received response data Drepl. 
If the content type Ictyp indicates HTML, the protocol control 
section Ppc passes the received response data Drepl to a language 
analysis portion (not shown) of the browser section Pbw, 
5 instructing to analyze the main content data Dmc in the response 
data Drepl . 

[0020] In response to the instruction, the browser section Pbw 
analyzes the structure and arrangement of the text represented 
by the content data Dmc, and then performs display processing for 

10 the text. In addition, the browser section Pbw extracts, as 
internal information, a set of the locational information lurl 
and the connection method information Iconnl from each of the 
anchor tags Tancl and Tanc2 . And the browser section Pbw 
describes the extracted information in an internal information 

15 table Tconnl held therein. As shown in FIG . 2B, the internal 
information table Tconnl is constructed to allow description of 
sets of the locational information lurl and the connection method 
information Iconnl therein. With this table, it is possible to 
indicate which connection method, the packet switching connection 

20 or the circuit switching connection, is suitable at the retrieval 
of the sub-content data Dsc. In this embodiment, the anchor tag 
Tancl includes the set of "href=urll" and w cc=Packet" as the 
connection method information Iconnll, and the anchor tag Tanc2 
includes the set of "href =url2 " and "cc-tel" as the connection 

25 method information Iconnl2 , as shown in FIG . 1. Therefore, 



described in the internal information table Tconnl are the set 
of urll and packet and the set of url2 and tel as shown in FIG. 
2B. Thus, it is indicated that the packet switching connection 
is suitable for the retrieval of the sub-content data Dscl, while 
5 the circuit switching connection is suitable for the retrieval 
of the sub-content data Dsc2 . 

[0021] When the sub-content data Dscl is to be retrieved, the 
protocol control section Ppc receives a retrieval request Dcreq 
including the locational information Iurl . This retrieval 

10 request Dcreq is automatically generated by the browser section 
Pbw. The retrieval request Dcreq is automatically generated when 
the sub-content data Dscl is embedded in the main content data 
Dmc. An example of this embedded data is shown in FIG. 3A, where 
a still picture represented by the sub-content data Dscl is pasted 

15 to text represented by the main content data Dmc. The protocol 
control section Ppc extracts the locational information Iurl from 
the received retrieval request Dcreq, and extracts the connection 
method information Iconnl pairing with this locational 
information Iurl (connection method information Iconnll in this 

20 case) from the internal information table Tconnl (see FIG- 2B) . 
The protocol control section Ppc determines which connection 
method, the packet switching connection or the circuit switching 
connection, should be adopted for the present sub-content data 
Dsc according to the extracted connection method information 

25 Iconnl. Since the connection method information Iconnll has been 



extracted in this case, the packet switching connection is 
determined suitable . 

[0022] Based on the above determination, the protocol control 
section Ppc passes the received retrieval request Dcreq to the 
5 first communication control section Peel , instructing to retrieve 
the sub-content data Dscl . In response to this instruction, the 
first communication control section Peel transmits the present 
retrieval request Dcreq to the content server 3 via the first 
communication path 4pkt if the first communication path 4pkt has 
10 been established. If not established, the first communication 
control section Peel first establishes the first communication 
path 4pkt to the content server 3 and then transmits thereto the 
present retrieval request Dcreq. 

[0023] Based on the locational information Iurl in the 
15 received retrieval request Dcreq, the content server 3 reads the 
content data Dc, and generates a response header He and response 
data Drep. The content data Dc read presently is sub-content data 
Dscl. The content server 3 generates a response header Hscl for 
the sub-content data Dscl. The response header Hscl is 
2 0 constructed as shown in FIG. 2A, where the content type Ictyp and 
the content data length Iclg respectively indicate the type and 
size of the presently read sub-content data Dscl. In this 
embodiment, the type of the sub-content data Dscl is a still 
picture as shown in FIG . 3A, and thus the type specified by the 
25 content type Ictyp is still picture. The content server 3 



generates response data Drep2 by adding the response header Hscl 
to the sub-content data Dscl, and sends the response data Drep2 
to the first communication path 4pkt. 

[0024] The first communication control section Peel of the 
5 content retrieval device la receives the response data Drep2 from 
the first communication path 4pkt and passes the data to the 
protocol control section Ppc as it is. The protocol control 
section Ppc identifies the type of the content data Dscl from the 
preceding content type Ictyp in the received response data Drep2 . 

10 Once the protocol control section Ppc determines that the content 
type Ictyp indicates still picture, it passes the received 
response data Drep2 to a still picture display processing portion 
(not shown) of the browser section Pbw, instructing to carry out 
processing for displaying the sub-content data Dscl in the 

15 response data Drep2 . In response to the instruction, the browser 
section Pbw performs still picture display processing of the 
sub-content data Dscl. As a result, the browser section Pbw 
pastes the still picture represented by the sub-content data Dscl 
to the text represented by the main content data Dmc . 

20 [0025] Next, retrieval of the sub-content data Dsc2 will be 
described. Assume that the sub-content data Dsc2 is an audio file 
and embedded in the main content data Dmc. More specifically, 
as shown in FIG.3A, the audio represented by the sub-content data 
Dsc2 is played during the display of the text represented by the 

2 5 main content data Dmc. At the retrieval of the sub-content data 



Dsc2, the protocol control section Ppc receives a retrieval 
request Dcreq including the locational information lurl (that is, 
url2) from the browser section Pbw. The protocol control section 
Ppc extracts the locational information lurl from the received 
5 retrieval request Dcreq, and then extracts the connection method 
information Iconnl pairing with this locational information lurl 
(connection method information Iconnl2 in this case) from the 
internal information table Tconnl . The protocol control section 
Ppc determines the connection method to be adopted presently (the 

10 circuit switching connection in this case) according to the 
extracted connection method information Iconnl. 
[0026] Based on the above determination, the protocol control 
section Ppc passes the received retrieval request Dcreq to the 
second communication control section Pcc2, instructing to 

15 retrieve the sub-content data Dsc2 . In response to this 
instruction, the second communication control section Pcc2 
transmits the present retrieval request Dcreq to the content 
server 3 via the second communication path 4tel if the second 
communication path 4tel has been established. If not established, 

20 the second communication control section Pcc2 first establishes 
the second communication path 4tel to the content server 3 and 
then transmits thereto the present retrieval request Dcreq. 
[0027] Based on the locational information lurl specified in 
the received retrieval request Dcreq, the content server 3 reads 

25 the sub-content data Dsc2, and also generates a response header 

16 



Hsc2 (see FIG . 2A) for the present sub-content data Dsc2 . The 
content server 3 generates response data Drep3 by adding the 
response header Hsc2 to the sub-content data Dsc2 f and sends the 
response data Drep3 to the second communication path 4tei. 
5 [0028] The second communication control section Pcc2 of the 
content retrieval device la receives the response data Drep3 from 
the second communication path 4tel, and passes the data to the 
protocol control section Ppc as it is. The protocol control 
section Ppc identifies the type of the sub-content data Dsc2 from 

10 the content type Ictyp in the received response data Drep3 , Once 
the protocol control section Ppc determines that the content type 
Ictyp indicates an audio file, it passes the received response 
data Drep3 to an audio replay processing portion (not shown) of 
the browser section Pbw, instructing to replay audio represented 

15 by the sub-content data Dsc2. In response to the instruction, 
the browser section Pbw performs replay processing. As a result, 
an output section (not shown) outputs the audio together with the 
screen display as shown in FIG. 3A. 

[0029] As described above, the main content data Dmc includes 
20 the connection method information Iconnll and Iconnl2 suitable 
for retrieval of the sub-content data Dscl and Dsc2 . Therefore, 
by analyzing the main content data Dmc, the content retrieval 
device la is informed of the connection methods suitable for 
retrieving the sub-content data Dscl and Dsc2 prior to retrieval 
25 of the sub-content data Dscl and Dsc2 . In other words , the content 



retrieval device la can select the circuit switching connection 
prior to retrieval of the sub-content data Dsc2 , and thus retrieve 
an audio file or a moving picture file without communication delay 
or interruption of data communication. Likewise, the content 
5 retrieval device la can select the packet switching connection 
prior to retrieval of the sub-content data Dscl , and thus retrieve 
a file such as an email that does not require consideration to 
communication delay and interruption at relatively low 
communication cost, 
10 [0030] In the first embodiment, the suitable connection method 
is specified by the attribute value in the anchor tag Tanc . 
Alternatively, a new anchor tag may be defined separately from 
the normal anchor tag Tanc to specify the suitable connection 
method. 

15 [0031] In the above embodiment, the sub-content data Dscl and 
Dsc2 are embedded in the main content data Dmc (see FIG . 3A) . 
Alternatively, the sub-content data Dscl and Dsc2 may be linked 
to the main content data Dmc while representing contents 
independent of the main content data Dmc. More specifically, as 

20 shown in FIG. 3B, the contents represented by the main content 
data Dmc are first displayed. Once the user designates the anchor 
tag Tancl or Tanc2 in the context of the displayed contents, the 
content retrieval device la retrieves the sub-content data Dscl 
or Dsc2 . As a result, the displayed contents are switched to the 

25 contents represented by the sub-content data Dscl or Dsc2 . 
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[0032] An example of implementation of the content retrieval 
device la described above will be described. FIG . 4 is a block 
diagram of a mobile communication unit Ucomml incorporating the 
content retrieval device la. Referring to FIG. 4, the mobile 
5 communication unit Ucomml includes CPU 11, ROM 12, a RAM 13, the 
first communication control section Peel, the second 
communication control section Pcc2, an input device 14, an output 
device 15, a multiplexer/demultiplexer 16, and a 
transmitter/receiver 17. The CPU 11 executes a program stored 

10 in advance in the ROM 12. During execution of the program, the 
CPU 11 uses the RAM 13 as a working area. The CPU 11 in combination 
with the ROM 12 and the RAM 13 constitutes the browser section 
Pbw and the protocol control section Ppc (see FIG. 1) described 
above. The first communication control section Peel performs 

15 data communication under the packet switching connection under 
the control of the CPU 11. Likewise, the second communication 
control section Pcc2 performs data communication under the 
circuit switching connection under the control of the CPU 11 . The 
CPU 11, the ROM 12, the RAM 13, the first communication control 

20 section Peel, and the second communication control section Pcc2 
constitute the content retrieval device la. 

[0033] The input device 14 typically includes keys, buttons, 
and a jog dial, which are operated by the user. The output device 
15, which includes a liquid crystal display and a speaker, 
25 performs output processing for output data Dout generated by the 

19 



CPU 11 and presents the contents represented by the output data 
Dout to the user. The multiplexer/demultiplexer 16 multiplexes 
the retrieval request Dcreq received from the first communication 
control section Peel and the second communication control section 
5 Pcc2 f and also demultiplexes the content data Dc received from 
the transmitter/receiver 17. More specifically, since content 
data Dc directed to other mobile communication units Ucomml are 
also sent from the transmitter/receiver 17, the 
multiplexer/demultiplexer 16 demultiplexes the content data Dc 

10 directed to itself from the content data Dc directed to other units . 
The transmitter/receiver 17 sends the retrieval request Dcreq 
multiplexed by the multiplexer/demultiplexer 16 to the 
communication network 2. In addition, the transmitter /receiver 
17 receives the content data Dc transmitted via the communication 

15 network 2 and passes the data to the multiplexer/demultiplexer 
16. 

[0034] The operation of the mobile communication unit Ucomml 
will be described with reference to the flowchart of FIG. 5. The 
CPU 11 executes a program stored in the ROM 12. The user inputs 

20 locational information Iurl of content data Dc that he or she 
desires to retrieve this time through the input device 14. Assume 
that the locational information input presently is the locational 
information Iurl of the main content data Dmc (that is, urlO) . 
The CPU 11 first operates as the browser section Pbw to generate 

25 a retrieval request (stepSlOl) . More specif ically , atstepSlOl, 



the CPU 11 generates a retrieval request Dcreq including the 
locational information Iurl sent from the input device 14. 
[0035] The CPU 11 then operates as the protocol control section 
Ppc to determine whether or not the connection has been 
5 established (step S102) . More specifically, at step S102, the 
CPU 11 determines whether or not access to the server 3 (see FIG. 
1) is possible under either the packet switching connection or 
the circuit switching connection. If the connection has not been 
established, the CPU 11 passes the present retrieval request Dcreq 
10 to the first communication control section Peel, instructing to 
retrieve the main content data Dmc {step S103) . The above series 
of processing until step S103 are those executed by the protocol 
control section Ppc. 

[0036] In response to the instruction from the CPU 11 , the first 
15 communication control section Peel establishes the first 
communication path 4pkt to the content server 3 (step S104) . Once 
the first communication path 4pkt has been established, the first 
communication control section Peel passes the retrieval request 
Dcreq to the multiplexer /demultiplexer 16. The 
20 multiplexer/demultiplexer 16 then multiplexes the received 
retrieval request Dcreq and passes the multiplexed retrieval 
request Dcreq to the transmitter/receiver 17, which sends the 
multiplexed retrieval request Dcreq to the first communication 
path 4pkt . In this way , the presently generated retrieval request 
25 Dcreq is sent to the first communication path 4pkt (step S105) . 



The server 3 receives the retrieval request Dcreq, and in response 
to the received retrieval request Dcreq, generates response data 
Drepl (see FIG. 2 A) , which is sent to the first communication path 
4pkt . 

5 [0037] In the mobile communication unit Ucomml , the 
transmitter/receiver 17 receives the response data Drepl from the 
first communication path 4pkt and passes the data to the 
multiplexer /demultiplexer 16. The multiplexer/demultiplexer 16 
demultiplexes the response data Drepl directed to itself from 

10 those directed to other units, and passes the data to the first 
communication control section Peel. The first communication 
control section Peel passes and stores the received response data 
Drepl as it is to the RAM 13. In this way, the response data Drepl 
is received by the mobile communication unit Ucomml (step S106) . 

15 Once the response data Drepl is stored in the RAM 13, the CPU 11 
operates as the protocol control section Ppc to determine the type 
of the main content data Dmc from the preceding content type Ictyp 
in the received response data Drepl (step S107) . More 
specifically, the CPU 11 determines whether or not the main 

20 content data Dmc is described in HTML . In this case, the content 
type Ictyp in the response data Drepl indicates HTML. Therefore, 
the CPU 11 proceeds to step S108. 

[0038] The CPU 11 then operates as the browser section Pbw to 
analyze the main content data Dmc and extract sets of the 
25 locational information lurl and the connection method information 



Iconnl from the anchor tags Tancl and Tanc2 as internal 
information. The CPU 11 describes the extracted sets of the 
locational information lurl and the connection method information 
Iconnl in the internal information table Tconnl . In this way, 
5 the internal information table Tconnl is created (step S108) . The 
CPU 11 also analyzes the structure and arrangement of the text 
represented by the main content data Dmc, and generates output 
data Dout in the RAM 13 (step S109) . The output data Dout is 
transferred to the output device 15, which performs display 

10 processing according to the output data Dout. 

[0039] When the sub-content data Dscl or Dsc2 is to be retrieved 
by the mobile communication unit Ucomml , the CPU 11 generates a 
content retrieval request Dcreq (step S101) . This time, the 
retrieval request Dcreq is automatically generated by the CPU 11, 

15 and includes the locational information lurl (that is, urll or 
url2) . The CPU 11 determines whether or not the connection has 
been established (step S102) . This time, the first communication 
path 4pkt is available for data communication. The CPU 11 
therefore determines that the connection has been established. 

2 0 The CPU 11 then determines whether or not the content data Dc to 
be retrieved presently is sub-content data Dsc (stepSlOlO) . More 
specifically, the CPU 11 determines whether or not the connection 
method information Iconnl pairing with the locational information 
lurl in the presently prepared retrieval request Dcreq is found 

25 in the internal information table Tconnl (see FIG. 233) created 



at step S108. 

[0040] If the connection method information Iconnl is not 
found in the table, the content data Dc to be retrieved presently 
must be main content data Dmc. The CPU 11 therefore goes to step 
5 S105 to execute the subsequent process steps. If the connection 
method information Iconnl is found in the table, the content data 
Dc to be retrieved presently is considered to be sub-content data 
Dsc. The CPU 11 then extracts the connection method information 
Iconnl {the connection method information Iconnll or Iconnl2) 
10 pairing with the locational information Iurl from the internal 
information table Tconnl (step S1011) . Thereafter, the CPU 11 
determines whether or not the extracted connection method 
information Iconnl indicates the second communication path 4tel 
{step S1012) . 

15 [0041] If the present retrieval request Dcreq includes urll 
as the locational information Iurl, the connection method 
information Iconnll has been extracted at step S1011. In this 
case, the CPU 11 determines that the extracted connection method 
information Iconnl does not indicate the second communication 

2 0 path 4 tel. That is, the CPU 11 determines retrieval of the 
sub-content data Dscl through the first communication path 4pkt 
as in the main content data Dmc. 

[0042] If the present retrieval request Dcreq includes url2 
as the locational information Iurl, the connection method 
25 information Iconnl2 has been extracted at step S1011. In this 



case, the CPU 11 determines that the extracted connection method 
information Iconnl indicates the second communication path 4tel- 
That is, the CPU 11 determines retrieval of the sub-content data 
Dsc2 under the circuit switching connection. The CPU 11 then 
5 proceeds to step S1013, and first instructs the first 
communication control section Peel to cut the connection 
(disconnect the first communication path 4pkt) . The CPU 11 then 
passes the presently generated retrieval request Dcreq to the 
second communication control section Pcc2 , instructing to 
10 retrieve the sub-content data Dsc2 (stepS1013). The above series 
of processing from steps S1010 through S1013 are also those 
executed by the protocol control section Ppc. 

[0043] In response to the instruction from the CPU 11 , the first 
communication control section Peel disconnects the first 

15 communication path 4pkt that has been established as the path to 
the content server 3. Also, in response to the instruction from 
the CPU 11, the second communication control section Pcc2 
establishes the second communication path 4tel to the content 
server 3 according to the circuit switching connection 

20 requirements (step S1014) . Once the second communication path 
4tel has been established, the second communication control 
section Pcc2 passes the retrieval request Dcreq to the 
multiplexer/demultiplexer 16 . The multiplexer/demultiplexer 16 
then multiplexes the received retrieval request Dcreq and passes 

25 the multiplexed retrieval request Dreq to the 

25 



transmitter/receiver 17, which sends the multiplexed retrieval 
request Dcreq to the second communication path 4tel. In this way, 
the presently generated retrieval request Dcreq is sent to the 
second communication path 4tel (step S105) . As a result, the 
5 sub-content data Dsc2 is retrieved via the second communication 
path 4tel, unlike the main content data Dmc . 

[0044] As described above with reference to FIG. 3A, the 
sub-content data Dscl and Dsc2 represent still picture and audio, 
and thus are not described in HTML to the strict sense . Therefore , 

10 principally, the determination by the CPU 11 at step S107 is NO. 
In this case, the CPU 11 skips the step of extracting internal 
information from the sub-content data Dscl and Dsc2 . The CPU 11 
then generates the output data Dout based on the sub-content data 
Dscl and Dsc2 and transfers the output data Dout to the output 

15 device 15 (step S109) . The output device 15 performs still 
picture display processing and audio replay processing according 
to the received sub-content data Dscl and Dsc2 . 
[0045] FIG. 6 is a functional block diagram of a content 
retrieval device lb of a second embodiment of the present 

20 invention. FIG. 6 also shows a communication network 2 and a 
content server 3 in association with the content retrieval device 
lb. As the content retrieval device la, the content retrieval 
device lb has a multi-call function that permits access to the 
content server 3 via a first communication path 4pkt during the 

25 packet switching connection and access to the content server 3 
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via a second communication path 4tel during the circuit switching 
connection. The content retrieval device lb is different from 
the content retrieval device la in that a connection information 
management section Pconnl is additionally provided to realize the 
5 data communication described above. The other construction of 
the content retrieval device lb is the same as that of the content 
retrieval device la. In FIG. 6, therefore, the same components 
as those in FIG. 1 are denoted by the same reference numerals. 
[0046] The connection information management section Pconnl 

10 holds in advance and manages a connection information table Tconn2 
as shown in FIG. 7A. The connection information table Tconn2 
includes in advance sets of the content type Ictyp and the 
connection method information Iconnl that is the same as that in 
the first embodiment. The content type Ictyp indicates the type 

15 of each content data Dc. This table therefore shows which 
connection method, the packet switching connection or the circuit 
switching connection, is suitable for each content type Ictyp of 
the content data Dc. In this embodiment, the content type Ictyp 
of text/html is allocated to an HTML file, while the content type 

20 Ictyp of video/mpeg is allocated to a moving picture file. Since 
communication delay and interruption of data communication are 
not fatal to the HTML file, text/html preferably pairs with the 
connection method information Iconnll (packet switching 
connection) . Also, since communication delay and interruption 

25 are fatal to the moving picture file, video/mpeg preferably pairs 
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with the connection method information Iconnl2 (circuit switching 
connection) . 

[0047] The content server 3 stores some content data Dc as in 
the first embodiment. In the first embodiment, the suitable 
5 connection method itself (connection method information Iconnl) 
is described in the main content data Dmc as the attribute value 
of the anchor tag Tanc. In the second embodiment, however, as 
the attribute value of the anchor tag Tanc, the content type Ictyp 
indicating the type of the sub-content data Dsc is described. In 

10 this embodiment, prepared are two content types Ictyp: content 
type Ictypl indicating that the sub-content data Dsc specified 
by the anchor tag Tanc is an HTML file , described as type=text/html , 
and content type Ictyp2 indicating that the sub-content data Dsc 
specified by the anchor tag Tanc is a moving picture file, 

15 described as type=video/html . 

[0048] FIG. 6 exemplifies one main content data Dmc and two 
sub-content data Dscl and Dsc2 as the sub-content data Dsc. The 
locational information Iurl of the main content data Dmc is urlO. 
Assume that the sub-content data Dscl is an HTML file to which 

20 communication delay and interruption of data communication are 
not fatal and that the sub-content data Dsc2 is a moving picture 
file to which communication delay and interruption are fatal, as 
described above. Assume also that the locational information 
Iurl of the sub-content data Dscl and Dsc2 are urll and url2, 

25 respectively. Under the above assumption, the main content data 
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Dmc has descriptions of two anchor tags Tancl and Tanc2 . The 
anchor tag Tancl includes descriptions of "href=urll" and 
"type=text/html" , while the anchor tag Tanc2 includes 
descriptions of "href=ur!2" and w type=video/mpeg" . 
5 [0049] The operation of the content retrieval device lb having 
the above construction will be described. The content retrieval 
device lb retrieves the main content data Dmc from the content 
server 3 in substantially the same manner as the content retrieval 
device la of the first embodiment. That is, the protocol control 

10 section Ppc passes the main content data Dmc to the browser section 
Pbw instructing to analyze the data. In response to this 
instruction, the browser section Pbw analyzes the structure and 
arrangement of the text represented by the content data Dmc to 
generate output data Dout representing the text. In addition, 

15 the browser section Pbw extracts sets of the locational 
information Iurl and the content type Ictyp from the anchor tags 
Tancl and Tanc2 of the presently received content data Dmc as 
internal information, and describes and holds the internal 
information in the internal information table Tctyp. As shown 

2 0 in FIG. 7B, the internal information table Tctyp is constructed 
in advance to allow description of sets of the locational 
information Iurl and the content type Ictyp therein, so that the 
content type Ictyp of each sub-content data Dsc is identified from 
this table. In the illustrated example, the anchor tag Tancl 

25 includes the set of "href=urll" and "type=text/html" , and the 



anchor tag Tanc2 includes the set of "href=url2" and *type= 
video/mpeg" , as shown in FIG. 6. Therefore, described in the 
internal information table Tctyp are the set of urll and text/html 
and the set of url2 and video/mpeg. 
5 [0050] When the sub-content data Dscl is to be retrieved, the 
protocol control section Ppc receives a retrieval request Dcreq 
including urll as the locational information Iurl from the browser 
section Pbw. The protocol control section Ppc extracts the 
locational information Iurl from the received retrieval request 

10 Dcreq f and extracts the content type Ictyp (text/html in this 
case) pairing with the present locational information Iurl from 
the internal information table Tctyp {see FIG. 7B) of the browser 
section Pbw. The protocol control section Ppc then determines 
which connection method, the packet switching connection or the 

15 circuit switching connection, should be adopted for the sub- 
content data Dsc to be retrieved presently. For this purpose, 
the protocol control section Ppc inquires of the connection 
information management section Pconnl about whether or not the 
connection information table Tconn2 includes a content type 

20 matching with the content type Ictyp extracted from the internal 
information table Tctyp. If the connection information table 
Tconn2 includes a content type matching with the inquired content 
type Ictyp , the connection information management section Pconnl 
returns the connection method information Iconnl (connection 

25 method information Iconnll (packet) in this case) pairing with 
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the content type Ictyp in question to the protocol control section 
Ppc. The protocol control section Ppc determines which 
connection method, the packet switching connection or the circuit 
switching connection, should be adopted for the sub-content data 
5 Dscl to be retrieved presently according to the connection method 
information Iconnl fetched from the connection information 
management section Pconnl . In this case, since the connection 
method information Iconnll is fetched, the packet switching 
connection is determined suitable. The subsequent operation is 
10 substantially the same as that of the first embodiment, and thus 
the description thereof is omitted here. 

[0051] When the sub-content data Dsc2 is to be retrieved, the 
protocol control section Ppc receives a retrieval request Dcreq 
including url2 as the locational information Iurl. From the 

15 received retrieval request Dcreq, the protocol control section 
Ppc extracts the content type Ictyp (video/mpeg in this case) 
pairing with the locational information Iurl from the internal 
information table Tctyp of the browser section Pbw. The protocol 
control section Ppc then inquires of the connection information 

20 management section Pconnl about whether or not the connection 
information table Tconn2 includes a content type matching with 
the content type Ictyp extracted from the internal information 
table Tctyp. If the connection information table Tconn2 includes 
the matching content type, the connection information management 

25 section Pconnl returns the connection method information Iconnl 



(connection method information Iconnl2 (tel) in this case) 
pairing with the content type Ictyp in question to the protocol 
control section Ppc . The protocol control section Ppc determines 
which connection method, the packet switching connection or the 
circuit switching connection, should be adopted for the sub- 
content data Dsc2 to be retrieved presently according to the 
connection method information Iconnl fetched from the connection 
information management section Pconnl . In this case, since the 
connection method information Iconnl2 is fetched, the circuit 
switching connection is determined suitable. The subsequent 
operation is substantially the same as that of the first 
embodiment, and thus the description thereof is omitted here. 
[0052] As described above, the main content data Dmc includes 
the content type Ictyp of each of the sub-content data Dscl and 
Dsc2 . Also, the content retrieval device lb holds the connection 
information table Tconn2 in which sets of the content type Ictyp 
and the connection method information Iconnl are described in 
advance. The content retrieval device lb analyzes the main 
content data Dmc and describes sets of the locational information 
Iurl and the content type Ictyp in the internal information table 
Tctyp. By referring to the internal information table Tctyp and 
the connection information table Tconn2 , the content retrieval 
device lb is informed of the connection method suitable for 
retrieving the sub-content data Dsc prior to retrieval of the 
sub-content data Dsc. 



[0053] In the second embodiment, the content type Ictyp is 
described in the content data Dc, and the connection information 
management section Pconnl managed the connection method 
information Iconnl in association with the content type Ictyp. 
Alternatively, the connection method information Iconnl may be 
managed in association with an attribute of the content data Dc 
if the attribute is described in the content data Dc. A typical 
example of the attribute of the content data Dc includes the file 
name, the file extension, and the content length Iclg. In 
particular, if the content length Iclg is described in the content 
data Dc and the connection information management section Pconnl 
manages the connection method information Iconnl in association 
with the content length Iclg, the connection method information 
Iconnl to be fetched is determined by comparing the length Iclg 
of the content data Dc to be retrieved with the content length 
Iclg managed by the connection information management section 
Pconnl . 

[0054] In the second embodiment, the content type Ictyp is 
described in the content data Dc. Alternatively, the content 
retrieval device lb may retrieve part of the sub-content data Dsc 
in advance and analyze the part of the data, to specify the data 
format (that is, the content type Ictyp) of the present content 
data Dsc. The content retrieval device lb then fetches the 
connection method information Iconnl based on the specified 
content type Ictyp. 



[0055] Hereinafter, a mobile communication unit Ucomm2 
incorporating the content retrieval device lb described above 
will be described. The mobile communication unit Ucomm2 has 
substantially the same construction as the mobile communication 
5 unit Ucomml . Therefore, FIG. 4 will be referred to in the 
following description. The operation of the mobile 

communication unit Ucomm2 will be described with reference to the 
flowchart of FIG. 8. The flowchart of FIG. 8 is the same as the 
flowchart of FIG. 5 except that steps S108, S1010, and S1011 are 

10 replaced with steps S201, S202, and S203. In FIG. 8, therefore, 
steps corresponding to the steps in FIG. 5 are denoted by the same 
reference numerals, and the description thereof is omitted here. 
[0056] When the mobile communication unit Ucomm2 is to 
retrieve the content data Dc, first, the CPU 11 reads a program 

15 from the ROM 12 to the RAM 13. The program in this embodiment 
includes the connection information table Tconn2 shown in FIG. 
7A in advance. The connection information table Tconn2 is read 
to the RAM 13 during the read of the program. The mobile 
communication unit Ucomm2 executes steps S101 through S107 for 

20 retrieval of the main content data Dmc . Since the content type 
Ictyp of the response data Drepl (see FIG. 2A) indicates HTML, 
the CPU 11 proceeds from step S107 to step S201, where the CPU 
11 analyzes the main content data Dmc to extract the sets of the 
locational information Iurl and the connection method information 

25 Iconnl from the anchor tags Tancl and Tanc2 as internal 
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information. The CPU 11 stores the extracted internal 
information in the RAM 13 and describes the internal information 
table Tctyp shown in FIG. 7B (step S201) . The CPU 11 then proceeds 
to step S109. 

5 [0057] When the mobile communication unit Ucomm2 is to 
retrieve the sub-content data Dscl or Dsc2 , the CPU 11 executes 
steps S101 and S102 and then proceeds to step S202, where the CPU 
11 determines whether or not the content data Dc to be retrieved 
presently is sub-content data Dsc (step S202) . More specifically, 
10 the CPU 11 determines whether or not the same locational 
information as the locational information Iurl included in the 
presently generated retrieval request Dcreq is found in the 
internal information table Tctyp (see FIG. 7B) described at step 
S201. 

15 [0058] If the same locational information Iurl is not found 
in the table, the content data Dc to be retrieved presently is 
main content data Dmc. The CPU 11 therefore goes to step S105. 
If the same locational information Iurl is found in the table, 
the content data Dc to be retrieved presently is considered to 

20 be sub-content data Dsc. The CPU 11 then proceeds to step S203, 
where the CPU 11 extracts the content type Ictyp (text/html or 
video/mpeg) pairing with the extracted locational information 
Iurl from the internal information table Tctyp. Thereafter, the 
CPU 11 accesses the connection information table Tconn2 read in 

25 the RAM 13 together with the program, to extract the connection 
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method information Iconnl (packet or tel) pairing with the 
extracted content type Ictyp. The CPU 11 then proceeds to step 
S1012. The subsequent processing is the same as that of the first 
embodiment, and thus the description thereof is omitted here. 
5 FIG. 9 is a functional block diagram of a content 

retrieval device lc of a third embodiment of the present invention . 
FIG. 9 also shows a communication network 2 and a content server 
3 in association with the content retrieval device lc. As the 
content retrieval device la, the content retrieval device lc has 

10 a multi-call function that permits access to the content server 
3 via a first communication path 4pkt during the packet switching 
connection and access to the content server 3 via a second 
communication path 4tel during the circuit switching connection. 
The content retrieval device lc is different from the content 

15 retrieval device la in that a connection information management 
section Pconn2 is additionally provided to realize the data 
communication described above. The other construction of the 
content retrieval device lc is the same as that of the content 
retrieval device la. In FIG. 9, therefore , the same components 

20 as those in FIG. 1 are denoted by the same reference numerals. 
[0059] The connection information management section Pconn2 
manages a connection information table Tconn3 shown in FIG. 10, 
which includes in advance sets of a part representing a feature 
of the locational information Iurl and the connection method 

25 information Iconnl that is the same as that in the first embodiment. 



The locational information Iurl (that is, url) is uniquely 
allocated to each content data Dc, indicating the storage location 
of the content data Dc . Part of the locational information Iurl 
represents a feature of the content data Dc . More specifically, 
5 the locational information Iurl includes as a suffix an extension 
representing a feature of the content data Dc. Therefore, by 
referring to the set of the feature of the locational information 
Iurl and the connection method information Iconnl, it is 
identified which connection method, the packet switching 

10 connection or the circuit switching connection, is suitable for 
each feature (extension) of the locational information Iurl. In 
general, locational information Iurl having a form like 
http : //www . xxx . co . jp/yyy . html is allocated to an HTML file , where 
the extension is .html. Communication delay and interruption of 

15 data communication are not fatal to the HTML file. 
Therefore, .html preferably pairs with the connection method 
information Iconnll (packet switching connection) . Likewise, 
locational information Iurl having a form like 
http://www.xxx.co.jp/zzz.mpg is allocated to a moving picture 

20 file when the file is created according to MPEG (Motion Picture 
Experts Group) , where the extension is .mpg. Communication delay 
and interruption are fatal to the moving picture file. 
Therefore, .mpg preferably pairs with the connection method 
information Iconnl2 (circuit switching connection) . 

25 [0060] The content server 3 stores some content data Dc (three 



in the illustrated embodiment) as in the first embodiment. The 
locational information Iurl described above is allocated to each 
content data Dc . In the first embodiment , the suitable connection 
method itself is described in the main content data Dmc as the 
5 attribute value of the anchor tag Tanc. In the third embodiment, 
the anchor tag Tanc has nothing to do with the nature of the content 
retrieval device lc, and thus is not shown in this embodiment. 
[0061] The operation of the content retrieval device lc having 
the above construction will be described. The protocol control 

10 section Ppc receives a content retrieval request Dcreq including 
the locational information Iurl of the content data Dc. In 
response to the received retrieval request Dcreq, the protocol 
control section Ppc determines the connection method suitable for 
retrieval of the present content data Dc. Specifically, first, 

15 the protocol control section Ppc extracts the feature, that is, 
the extension of the locational information Iurl from the received 
retrieval request Dcreq. The protocol control section Ppc then 
inquires of the connection information management section Pconn2 
about whether or not the feature matching with the presently 

20 extracted feature of the locational information Iurl is found in 
the connection information table Tconn3 . If the connection 
information table Tconn3 includes the feature matching with the 
inquired feature of the locational information Iurl, the 
connection information management section Pconn2 returns the 

25 connection method information Iconnl pairing with this feature 
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of the locational information Iurl to the protocol control section 
Ppc. The protocol control section Ppc determines which 
connection method , the packet switching connection or the circuit 
switching connection, should be adopted for the content data 
5 Dc to be retrieved presently according to the received connection 
method information Iconnl. The subsequent operation is 
substantially the same as that of the first embodiment, and thus 
the description thereof is omitted here. 

[0062] As described above , each content data Dc has locational 
10 information Iurl allocated thereto representing the feature of 
the content data Dc . The content retrieval device lc holds in 
advance the connection information table Tconn3 including 
description of the connection method information Iconnl in 
association with the feature of the locational information Iurl. 
15 The content retrieval device lc extracts the feature of the 
locational information Iurl from the retrieval request Dcreq, and 
by using the extracted feature of the locational information Iurl 
and referring to the connection information table Tconn3, the 
content retrieval device lc is informed of the connection method 
20 suitable for retrieving the content data Dc prior to retrieval 
of the content data Dc. 

[0063] In the third embodiment, the connection method 
information Iconnl is described in the connection information 
table Tconn3 in association with the extension, so that the 
25 protocol control section Ppc extracts the connection method 
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information Iconnl based on the extension of the iocational 
information lurl of the content data Dc to be retrieved. 
Alternatively, parts of the Iocational information lurl other 
than the extension, such as the host name, part or all of the path, 
5 the scheme, or the port number may be described in the connection 
information table Tconn3 . The protocol control section Ppc then 
extracts the connection method information corresponding to the 
information (the host name, part or all of the path, the scheme, 
or the port number) described in the connection information table 
10 Tconn3 using the Iocational information lurl of the content data 
Dc to be retrieved. 

[0064] Hereinafter, a mobile communication unit Ucomm3 
incorporating the content retrieval device 1c described above 
will be described. The mobile communication unit Ucomm3 has 

15 substantially the same construction as the mobile communication 
unit Ucomml. Therefore, FIG. 4 will be referred to in the 
following description. The operation of the mobile 

communication unit Ucomm3 will be described with reference to the 
flowchart of FIG. 11. 

20 [0065] When the mobile communication unit Ucomm3 is to 
retrieve the content data Dc , first, the CPU 11 reads a program 
from the ROM 12 to the RAM 13. The program in this embodiment 
includes the connection information table Tconn3 shown in FIG. 
10 in advance. The connection information table Tconn3 is read 

25 to the RAM 13 during the read of the program. When the content 



data Dc is to be retrieved by the mobile communication unit Ucomm3 , 
the CPU 11 first operates as the browser section Pbw to generate 
a retrieval request (step S301) . More specifically, at step S301 , 
the CPU 11 generates a retrieval request Dcreq including the 
5 locational information Iurl received from the input device 14. 
[0066] Thereafter, the CPU 11 operates as the protocol control 
section Ppc to extract an extension indicating the feature of the 
content data Dc to be retrieved presently from the presently 
extracted locational information Iurl (step S302) . The CPU 11 

10 then extracts the connection information Iconnl pairing with the 
presently extracted feature of the locational information Iurl 
from the connection information table Tconn3 in the RAM 13 (step 
S303) . The CPU 11 determines whether the present content data 
Dc should be retrieved under the packet switching connection or 

15 the circuit switching connection (step S304) according to the 
extracted connection method Information Iconnl. If the 
extracted information is connection method information Iconnll, 
the packet switching connection is determined suitable for the 
present retrieval of the content data Dc. If the extracted 

20 information is connection method information Iconnl2 , the circuit 
switching connection is determined suitable for the present 
retrieval of the content data Dc . 

[0067] Subsequently, the CPU 11 determines whether or not the 
connection to the content server 3 has been established (step 
25 S305) . More specifically, the CPU 11 determines whether or not 
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access to the server 3 (see FIG. 9) is possible under either the 
packet switching connection or the circuit switching connection. 
If the connection has not been established, the CPU 11 passes the 
presently generated retrieval request Dcreq to either the first 
5 communication control section Peel or the second communication 
section Pcc2 , instructing to retrieve the content data Dc (step 
S306) . At this step, if the packet switching connection is 
determined suitable at step S304, the presently generated 
retrieval request Dcreq is passed to the first communication 

10 control section Peel . Contrarily, if the circuit switching 
connection is determined suitable, the present retrieval request 
Dcreq is passed to the second communication control section Pcc2 . 
The above series of processing until step S306 are those executed 
by the protocol control section Ppc. 

15 [0068] The first or second communication control section Peel 
or Pcc2 establishes the first or second communication path 4pkt 
or 4tel, respectively, to the content server 3 only when 
instructed by the CPU 11 (step S307) . Once the first or second 
communication path 4pkt or 4tel has been established, the first 

20 or second communication control section Peel or Pcc2 passes the 
retrieval request Dcreq to the first or second communication path 
4pkt or 4tel via the multiplexer /demultiplexer 16 and the 
transmitter/receiver 17. In this way, the retrieval request 
Dcreq is output to the first or second communication path 4pkt 

25 or 4tel(step S308) . The server 3 receives the retrieval request 
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Dcreq, generates response data Drepl as shown in FIG. 2A in 
response to the request, and sends the response to the first or 
second communication path 4pkt or 4tel whichever has been 
currently established as the path to the mobile communication unit 
5 Ucomm3 . 

[0069] In the mobile communication unit Ucomm3 , the first or 
second communication control section Peel or Pcc2 receives the 
response data Drep directed to itself via the first or second 
communication path 4pkt or 4tel , the transmitter/receiver 17, and 

10 the multiplexer/demultiplexer 16. The first or second 
communication control section Peel or Pcc2 stores the received 
response data Drep in the RAM 13 as it is. In this way, the CPU 
11 receives the response data Drep. In the subsequent step, the 
CPU 11 operates as the protocol control section Ppc to analyze 

15 the response data Drep in the RAM 13 (step S309) . Thereafter, 
the CPU 11 operates as the browser section Pbw to generate output 
data Dout in the RAM 13 according to the content data Dc (step 
S310) . The output data Dout is transferred to the output device 
15 for output processing. 

20 [0070] In some cases, the content retrieval device 1c further 
generates a content retrieval request Dcreq after establishment 
of the connection. In such cases, the CPU 11 determines at step 
S305 that the connection has been established. The CPU 11 then 
determines whether or not switching of the connection is required 

25 (step S311) . More specifically, the CPU 11 determines whether 



or not the communication path 4 (the first communication path 4pkt 
or the second communication path 4tei) presently used for data 
communication with the content server 3 matches with the 
communication path 4 determined at step S304. If it matches, no 
5 new connection establishment is required, and thus the CPU 11 goes 
to step S307 . If the communication path 4 determined at step S304 
is different from that presently used, the CPU 11 proceeds to step 
S312, where the CPU 11 first instructs the first or second 
communication control section Peel or Pcc2 that is presently used 

10 for data communication to cut the connection (disconnect the first 
or second communication path 4pkt or 4tel) . The CPU 11 then passes 
the presently generated retrieval request Dcreq to the first or 
second communication control section Peel or Pcc2 that has been 
determined at step S304, instructing to retrieve the content data 

15 Dc (step S312) . Thereafter, the content retrieval device 1c 
executes step S308. 

[0071] FIG. 12 is a functional block diagram of a content 
retrieval device Id of a fourth embodiment of the present 
invention. FIG. 12 also shows a communication network 2 and a 

20 content server 3 in association with the content retrieval device 
Id. The content retrieval device Id has the same construction 
as the content retrieval device lb, and thus the description 
thereof is omitted here . The content server 3 stores some content 
data Dc (three in the illustrated example) as in the third 

2 5 embodiment. 



[0072] The operation of the content retrieval device Id having 
the above construction will be described. The protocol control 
section Ppc receives a content retrieval request Dcreq generated 
by the browser section Pbw. The content retrieval request Dcreq 
5 includes the locational information Iurl of the content data Dc 
to be retrieved presently, as in the above embodiments. In 
response to reception of the retrieval request Dcreq, the protocol 
control section Ppc generates a header retrieval request Dhreq, 
which is data requesting the content server 3 to transmit only 

10 a response header He for the content data Dc to be retrieved 
presently. The retrieval request Dhreq includes the locational 
information Iurl specifying the content data Dc. If data 
communication with the content server 3 has already been executed, 
the protocol control section Ppc passes the generated retrieval 

15 request Dhreq to the first or second communication control section 
Peel or Pcc2 that is presently performing data communication, 
instructing to retrieve the response header He. The first or 
second communication control section Peel or Pcc2 transmits the 
retrieval request Dhreq to the content server 3 via the first or 

20 second communication path 4pkt or 4tel only when instructed by 
the protocol control section Ppc. 

[0073] If no data communication with the content server 3 ha 
already been executed, the protocol control section Ppc passes 
the generated retrieval request Dhreq preferably to the first 
25 communication control section Peel, instructing to retrieve the 
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response header He. The first communication control section Peel 
is selected because the first communication path 4pkt is less 
expensive in communication cost. In response to the instruction 
from the protocol control section Ppc, the first communication 
5 control section Peel transmits the retrieval request Dhreq to the 
content server 3 via the first transmission path 4pkt. 
[0074] The content server 3 prepares the response header He 
for the content data Dc based on the locational information Iurl 
specified in the received retrieval request Dhreq. The format 
10 of the response header He is as shown in FIG. 2A. The prepared 
response header He is transmitted by the content server 3 to the 
content retrieval device Id via the first or second communication 
path 4pkt or 4tel . 

[0075] In the content retrieval device Id, the first or second 
15 communication control section Peel or Pcc2 receives the response 
header He via the first or second communication path 4pkt or 4tel , 
and passes the response header He to the protocol control section 
Ppc as it is. The protocol control section Ppc extracts the 
content type Ictyp from the received response header He, and 
20 extracts the connection method information Iconnl pairing with 
the extracted content type Ictyp from the connection information 
table Tconn2 (see FIG. 7A) in the connection information 
management section Pconnl . The protocol control section Ppc 
determines whether the present content data Dc should be retrieved 
25 under the packet switching connection or the circuit switching 
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connection according to the extracted connection method 
information Iconnl . If the connection method information 
Iconnll is extracted, the packet switching connection is 
determined suitable. Contrarily, if the connection method 
5 information Iconnl2 is extracted, the circuit switching 
connection is determined suitable. 

[0076] If the communication path 4 (the first communication 
path 4pkt or the second communication path 4tel) specified by the 
extracted connection method information Iconnl is the same as the 

10 communication path 4 used for the transmission of the header 
retrieval request Dhreq, the protocol control section Ppc passes 
the retrieval request Dcreq received from the browser section Pbw 
to the first or second communication control section Peel or Pcc2 
that is presently performing data communication, instructing to 

15 retrieve the content data Dc. The first or second communication 
control section Peel or Pcc2 transmits the retrieval request Dcreq 
to the content server 3 via the first or second communication path 
4pkt or 4tel only when instructed by the protocol control section 
Ppc. 

20 [0077] On the contrary, if the communication path 4 specified 
by the extracted connection method information Iconnl is 
different from the communication path 4 used for the transmission 
of the header retrieval request Dhreq, the protocol control 
section Ppc instructs the first or second communication control 

25 section Peel or Pcc2 that is presently performing data 



communication to cut the connection. The protocol control 
section Ppc then passes the retrieval request Dcreq received from 
the browser section Pbw to the first or second communication 
control section Peel or Pcc2 that is not presently performing data 
5 communication, instructing to retrieve the content data Dc. The 
first or second communication control section Peel or Pcc2 
disconnects the first or second communication path 4pkt or 4tel 
presently established as the path to the content server 3 only 
when instructed to disconnect by the protocol control section Ppc . 

10 The first or second communication control section Peel or Pcc2 
establishes the first or second communication path 4pkt or 4tel 
only when instructed to retrieve the content data Dc by the 
protocol control section Ppc, and transmits the retrieval request 
Dcreq to the content server 3. 

15 [0078] If the communication path 4 used for the transmission 
of the header retrieval request Dhreq is disconnected, the 
protocol control section Ppc passes the retrieval request Dcreq 
received from the browser section Pbw to the first or second 
communication control section Peel or Pcc2 that is specified by 

20 the extracted connection method information Iconnll , instructing 
to retrieve the content data Dc . The first or second 
communication control section Peel or Pcc2 establishes the first 
or second communication path 4pkt or 4tel as the path to the content 
server 3 only when instructed by the protocol control section Ppc, 

25 and transmits the retrieval request Dcreq to the content server 



3. The content server 3 reads the content data Dc based on the 
locational information Iurl specified in the received retrieval 
request Dcreq, and transmits the read content data Dc to the 
content retrieval device Id via the first or second communication 
5 path 4pkt or 4tel that is presently used for data communication. 
[0079] As described above, the content retrieval device Id 
retrieves the response header He of content data Dc before 
retrieving the content data Dc, and is informed of a connection 
method suitable for retrieval of the present content data Dc by 

10 referring to the content type Ictyp included in the retrieved 
response header He and the connection information table Tconn2 . 
[0080] In the fourth embodiment, the content type Ictyp is 

extracted from the response header He, and the connection 
information management section Pconnl managed the connection 

15 method information Iconnl in association with the content type 
Ictyp. Alternatively, an attribute of the content data Dc 
included in the response header He (for example, the content 
length Iclg) may be extracted, and the connection information 
management section Pconnl may manage the connection method 

20 information Iconnl in association with this attribute of the 
content data Dc. In particular, when the attribute of the content 
data Dc is the content length Iclg, the content retrieval device 
Id determines the connection method information Iconnl to be 
extracted by comparing the length Iclg of the content data Dc to 

25 be retrieved presently with the content length Iclg managed by 
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the connection information management section Pconnl. 
[0081] Hereinafter, a mobile communication unit Ucomm4 
incorporating the content retrieval device Id described above 
will be described. The mobile communication unit Ucomm4 has 
5 substantially the same construction as the mobile communication 
unit Ucomml . Therefore, FIG. 4 will be referred to in the 
following description. The operation of the mobile 

communication unit Ucomm4 will be described with reference to the 
flowchart of FIG. 13. FIG. 13 is the same as FIG. 11 except that 
10 steps S302 to S304 are replaced with steps S401 to S405. In FIG. 
13, therefore, steps corresponding to the steps in FIG. 11 are 
denoted by the same reference numerals, and the description 
thereof is omitted here. 

[0082] When the mobile communication unit Ucomm4 is to 
15 retrieve the content data Dc, first, the CPU 11 reads a program 

from the ROM 12 to the RAM 13. The program in this embodiment 

includes the connection information table Tconn2 shown in FIG. 

7A in advance. The connection information table Tconn2 is read 

to the RAM 13 during the read of the program. Thereafter, the 
20 CPU 11 generates a retrieval request (step S301) . The CPU 11 then 

operates as the protocol control section Ppc to generate a header 

retrieval request Dhreq (step S402) . 

[0083] The CPU 11 passes the generated retrieval request Dhreq 
to either the first communication control section Peel or the 
25 second communication control section Pcc2 . If data 



communication with the content server 3 has already been executed, 
the CPU 11 passes the generated retrieval request Dhreq to the 
communication control section that is presently performing data 
communication, instructing to retrieve the response header He. 
In response to the instruction from the CPU 11, the first or second 
communication control section Peel or Pcc2 transmits the 
retrieval request Dhreq to the content server 3 via the 
multiplexer/demultiplexer 16, the transmitter/receiver 17, and 
the first or second communication path 4pkt or 4tel. On the 
contrary, if no data communication has already been executed, the 
CPU 11 passes the generated retrieval request Dhreq to the first 
communication control section Peel . In response , the first 
communication control section Peel transmits the retrieval 
request Dhreq to the content server 3 via the 
multiplexer/demultiplexer 16, the transmitter/receiver 17, and 
the first communication path 4pkt. In this way, the header 
retrieval request Dhreq is transmitted to the content server 3 
(step S402) . 

[0084] The content server 3 generates the response header He 
and returns the response header He to the mobile communication 
unit Ucomm4 via the first or second communication path 4pkt or 
4tel. In the mobile communication unit Ucomm4 , the first or 
second communication control section Peel or Pcc2 receives the 
response header He via the first or second communication path 4pkt 
or 4tel, the transmitter/receiver 17, and the 



multiplexer/demultiplexer 16, and stores the response header He 
in the RAM 13 as it is. In this way, the CPU 11 receives the 
response header He (step S403) . The CPU 11 extracts the 
connection method information Iconnl pairing with the content 
5 type Ictyp in the received response header He from the connection 
information table Tconn2 (see FIG. 7A) in the RAM 13. The CPU 
11 determines whether the content data Dc should be retrieved 
under the packet switching connection or the circuit switching 
connection according to the extracted connection method 

10 information Iconnl (step S405) . Subsequently, the mobile 
communication unit Ucomm4 executes steps S305 through S312 that 
are substantially the same as those shown in FIG. 11. It should 
be noted however that the content server 3 may transmit only the 
content data Dc to the mobile communication unit Ucomm4 in 

15 response to the content retrieval request Dcreq. Transmission 
of the response header He is not necessarily required. 
[0085] In the first to fourth embodiments described above, 
HTML is adopted as the markup language. The content retrieval 
devices la to Id of the present invention can also perform the 

20 processing described above for content data Dc described in XML 
(eXtention Markup Language) . 

[0086] While the invention has been described in detail, the 
foregoing description is in all aspects illustrative and not 
restrictive. It is understood that numerous other modifications 
25 and variations can be devised without departing from the scope 



of the invention. 
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